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EXEQ  rr  rvi'i  si  immary 


More  than  ever,  toctay's  prcxjrani  imnacjors  arc  confront<xi  with 
(.xjtni'lfc'x  Lnterfact^  probionis.  Tn  an  onvironnitait  of  scarce  resources  and 
multi-national  undertakinqs,  manatiers  have  less  ccjntrol  over  nviny  of  fhe 
elements  of  their  systems.  Increaseci  emphasis  on  joint-service  prexjrams 
has  raised  the  level  of  interorqanixational  complexity  associated  with 
wt^apons  inteqration.  Sentiiivnt  atjainst  the  proliferation  of  system 
[X'cul  tar  equi(.m'nt  has  served  to  iiiake  ccMiimonal  ity  an  in^x^rtant  prcxiram 
ccxisi  derat  ion. 

All  these  factors  tc^nd  to  make  interface  manaqement  a vital  coq 
in  the  cn^eraJ  1 proiiram  manaqemt:'nt  prcxress.  This  report  intrcxluces  sont^ 
f Luidanx?nta  1 considerations  of  wiiat  is  involved  in  interface:'  nunatieim'nt . 

Tt  atteiTijits  to  qo  bt'yond  the  classical  approach  of  formi,  fit  and  func- 
tional intix)ration.  It  discusses  im^xirtant  interactions  up  and  down  the 
bureaucratic  chain  of  axrmnnd,  across  interfacinq  aqencies,  and  anxanq 
ni'inlx'rs  (,)f  the  qov'ernnx'ut-cont factor  ttvim.  It  evolves  the  exmeept  that 
interface  nvmaqi.'nx'nt  is  es.sentially  (.ircxir.im  nvinacjement  of  an  interfaci'' 
.system. 

Fin.illy,  a exnKX'f)tual  nKxk'l  of  an  interface^  prociram  is  iievelo[x\l 
to  qraphic.il  ly  dr>fine  where  sucli  a prtxiram  c.m  tx^  lountl,  and  to  intnxliux^ 
thtxx'  dist  inct  iv'i'  levels  ot  onitrol  that  an'  usually  pn'sent. 
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It  is  till' 
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author's  belief  that  such  a simplistic  model  may  be  of  general  use  to 
procjram  managers  as  they  scope  out  their  integration  tasks  and  formuJate 
an  interface  managencnt  approach. 
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aiAPTER  I 


INTRODUCTICN 

Purpose 

This  report  was  originally  intended  to  present  a comtorehensivo 
approach  to  interface  nrmagemcnt . This  writer  realized  early  that  a 
com{:irehensive  approach  might  have  linuted  value  to  other  readers.  It 
appeared  to  mo  that  the  relatively  small  amount  of  specific  guidance 
published  on  the  si±)ject  may  bo  a blessing  (intended  or  not)  to  the 
interface  imnager.  Certainly,  tlie  problems  associated  with  managbig 
different  interfaces  could  bo  as  varieci  as  the  different  systems  them- 
selves. What  might  be  of  value  tlien,  would  be  those  elements  of  any  in- 
terface' nvanagement  approach  that  could  be  viewed  as  applicable  to  more 
than  one  interface  problem.  With  this  in  mind,  the  purpose  of  this  re- 
port became  one  of  breciking  dcMn  the  business  of  interface  management 
int^j^^i'  fundamental  considerations  so  the  reader  might  judge  for  hinv- 
sclf  their  appliciibility  to  his  own  interfacing  recpiirements. 

This  report  is  not  intended  to  be  a substitute  for  Chapter  15  of 
AFSC  Panphlet  800-3  (1:15-1)  wfiich  the  author  considers  to  be  a good 
cjuide  to  interface  nvinagentent . Sptxri  fically,  the  principles  and  tech- 
ni(]U('S  for  dcx:umentation  and  control  of  jhysical  and  fvuictional  inter- 
faces as  set  forth  in  800-3  will  not  bc'  rcf^x'ated  herein,  thoiKih  I 
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cx>nsidor  tiiom  to  Ix'  fundiinn'iital  to  nt)st  interface  manaqomont  apt^roachos. 

Fti tiler,  till'  fxirpcise  of  tliis  rej-xart  is  to  qo  beyond  the  focus  of  800-3  and 
incliKie  otiier  considerations  in  adciition  to  tJiose  technical  problems  (form, 
fit  lUid  fiuiction)  historicaily  associated  with  interface  management. 

In  my  view,  the  lessons  of  prior  programs  involving  the  rranagcarent 
of  complex  technical  interfaces  have  been  well  learned.  I would  say  that 
the  present  bociy  of  interface  management  guidance  has  placed  a good  handle 
on  tlie  typo  of  physical  and  functional  interface  problem  that  can  be  illu- 
strated concx'pfually  by  Figure  1.  My  purpose  is  to  suggest  that  a program 
manager  n-  sider  other  aspects  of  his  interface  management  problem 

in  add  ,,ie  important  t^iysical  and  functional  conpatibility  issue. 

These  otlier  as|xacts  will  be  discussed  in  the  body  of  this  report.  In  the 
final  analysis,  I will  attenpt  to  modify  the  graphics  of  Figure  1 to  in- 
clude the  concept  of  these  additional  considerations. 

Approach 

This  report  is  a result  of  integrating  my  personal  o.xperiences  as 
the  F-15  Armament  Project  Manager  with  a review  of  selected  F-15  inter- 
face documentation,  other  relevant  reading  material,  and  intervievis  witJi 
two  Air  Force  program  managers  assigned  to  joint  service  missile  proqmms. 

An  analysis  of  F-15/Air-to-Air  missile  exf-xoriences  was  syntiiesi/xxi 
with  many  of  the  fundamental  princifjles  of  prexjram  iranagement  prcsenteci 
at  the  rX’fense  Systems  M^anagement  College  in  order  to  generalize  my' 
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observations.  Whenever  specific  exanples  were  roquirexi  they  were  drawn 
from  actual  situations  in  the  F- 15/Air- to- Air  missile  inteejration  pro- 
grams. 
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aiAFFER  II 


nvrrt:RFACE  management? 


Ttie  Systems  Acx]uisition  Elnvironmont 

Within  the  Executive  Branch  of  Government,  and  particularly  v/ithin 
the  Department  of  Defense  (DOD) , the  program  management  approach  to  sys- 
tems acejuisition  is  a natter  of  established  policy.  Program  managers 
(especially  those  in  charge  of  major  weajxans  accyuisition  programs  witliin 
the  DOD)  are  given  broad  areas  of  "rcsfX)nsibility,  autlrarity  and  accouJit- 
ability  for  program  objectives."  (2:5)  Still,  the  anount  of  actual  control 
a program  iranager  can  exercise  over  some  elenents  vital  to  his  program 
tends  to  vary  both  in  scope  and  degree.  This  is  especially  true  today 
v\hen  scarce  resources  and  rising  costs  are  placing  constraints  such  as 
standardization,  interoperability,  and  tlie  use  of  existing  or  conrvrcial 
hardware  and  software  on  the  procjram  manager's  choice  of  alternative's. 


As  a result,  today's  weapon  system  proc;ram  nanager  rarely  has  total 
control  over  all  of  the  elements  that  na)<e  up  his  system.  He  is  forced 
to  share  control  on  sona  vital  elements  witii  other  prociram  nanagers.  These 
other  managers  can  be  in  the  same  service,  a different  service,  a dif- 


ferent agency  or  even  a different  covuitry.  This  is  where  interface'  nnn- 
aejement  becomes  an  extremely  im^wrtant  part  of  proi]ram  nonageiTient . It 
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c£in  and  must  provide  the  program  manager  with  a means  of  wresting  suf- 
ficient control  from  the  other  guy's  program. 

But,  what  is  sufficient?  Is  it  sufficient  to  control  the  technical 
or  hardware  interfaces  to  the  point  of  insuring  that  they  are  ccmpatible? 

To  what  extent  is  the  balance  of  cost,  schedule  and  technical  performance 
in  one  program  affected  by  the  balance  of  those  same  factors  in  another 
program  with  which  it  must  interface?  The  program  manager's  answers  to 
these  questions  will  go  a long  way  toward  determining  the  amount  of  entasis 
he  will  place  on  interface  management.  Given  enough  attention,  interface 
management  can  be  the  key  to  program  success.  Neglected,  it  can  be  the 
reason  for  a program's  demise. 

Organizational  Relationships 

The  interface  management  approach  or  technique  that  a program  man- 
ager chooses  can  be  greatly  influenced  by  the  organizational  relation- 
ships inposed  on  his  situation.  His  basic  objective  will  always  be  to 
gain  control  over  those  parts  of  another  manager's  program  that  are  crit- 
ical to  his  own  success.  The  means  of  gaining  control  available  to  a pro- 
gram manager  can  vary  widely  with  the  situation. 

For  example,  a program  nvinager  may  bo  given  the  opportunity  to 
apply  a subsystem  approach  to  his  interface  problem.  This  would  have  been 
the  case  with  the  Aim- 82  short  range  missile  that  was  to  have  been  de- 
velopt?d  as  a "subsystem"  for  the  Air  Forcx^'s  F-15  fighter.  Organizationally, 
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the  undertaking  was  started  as  a program  within  a program  with  the  Aim  82 
program,  manager  working  for  the  F-15  program  manager.  He  and  his  staff 
were  physically  located  within  the  F-15  program  office.  With  this  kind 
of  internalized  approach  it  would  not  be  too  much  to  expect  that  the  air- 
craft manager  would  maximize  the  amount  of  his  control  over  the  mxssile 
program. 

On  the  other  hand,  when  the  Aim- §2  program  was  denied  by  OSD  in 
favor  of  an  improved  version  of  the  Navy's  sidewinder  missile,  tiie  Aim-9L, 
the  situation  chcinged  draimatically.  The  Aim-9L  entered  development  as  a 
joint  Navy-Air  Force  undertaking  with  the  Navy  as  the  executive  service. 

A joint  program  office  was  formed  at  Naval  Air  Systems  Command,  Washington, 
D.C. , with  a Navy  program  manager  and  ^^n  Air  Force  deputy  program  manager. 
The  Air  Force  deputy  reported  to  Air  Force  Systems  Cemmand,  Andrews  AFB, 

MD. , through  the  Armaiment  Development  and  Test  Center,  Eglin  AFB,  FL. 
Furthermore,  Aim-9L  program  direction  required  the  Air  Force  manager  to 
develop  his  missile  to  be  compatible  with  the  F-4E  aircraft  only,  and  to 
provide  interface  data  to  "other"  Air  Force  user  aircraft.  Clearly,  for 
the  F-15  program  manager,  sitting  in  his  office  at  Aeronautical  Systems 
Division,  Dayton,  Chio,  there  was  a different  set  of  choices  available 
for  managing  the  interface  between  the  F-15  and  Aim-9L  than  had  existed 
with  the  Airr.-82. 


Even  when  faced  with  more  cornfalex  interorgajiizational  relation- 


ships and  less  opportunities  for  direct  control,  a procjram  manager  should 
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not  change  his  basic  objective  of  gaining  control  over  those  [jarts  of 

another  piogrtun  that  are  critical  to  his  success.  At  times  he  may  be 

tempted  to  take  the  approach  that  the  other  system  is  outside  of  his 
own  system  boundaries  and  beyond  the  scope  of  his  responsibility  - the 
"govcrniamt  furnished  etjuiiaiient"  attitude  or  syndrome.  He  should  resist 
the  tenptation.  If  the  other  weapon  is  indeed  important  to  his  own  sys- 
tem's effectiveness,  ignoring  it  is  inviting  disaster.  Organizational 
relationships  should  only  impact  a procjrOTi  ntinager’s  interface  nvinagement 
approaches,  not  his  object ivos. 

Organizing  for  Interface  Management 

The  prcxjrtmi  nvinager  w*ao  has  evaluated  his  organizational  relation- 
ships with  other  prexjrams  and  has  narrowed  his  chcucc'  of  interface.''  nun- 

agemf'nt  approaches  should  turn  to  structuring  his  owii  orgajiization  to 

nvatch  his  final  choice.  The  "subsystem"  approach  has  already  Ixvn  nt'ii- 
tioned.  Here  the  interface  task  would  lx.'  viewexJ  as  critical  to  thi'  pro- 
gram's success.  The  objective  would  bc'  to  establish  a nearly  self-sul- 
ticient  [project  witliLn  a program  office  in  order  to  centralize  and  in- 
tensify the  interface'  nvinaepment  process.  Tht'  expt'cted  result  would  be' 
nvaximimi  int''nration  of  the  plarming,  directing  and  control liiig  proct'sses 
for  both  proeir^ims.  A d i sadvantacjt>  would  bt'  the  complexity  and  size  of 
the  result.ant  protjnmi  office.  We  have  already  said  that  in  texi.jy's 
scarce  resource  c'nvironmt'nt  the'  prexjram  nvinatjer  will  likely  Ix'  torcixl 
to  tjivx'  up  some'  (x^ntrol  Ix'caust'  of  desirt'd  cxxnionality  of  wi'apms.  It 
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is  also  true  that  today's  nianager  is  being  forced  to  share  his  hunon 

; resources  with  other  managers. 

[ 

i For  these  reasons,  the  pragmatic  program  manager  will  likely  con- 

sider a snnll  interface  project  group,  a single  interface  manager,  or  a 

! direct  integration  of  the  interface  function  into  the  existing  program 

I 

structure.  The  matrix  approach  entxxlied  in  the  use  of  a small  project 

1 

group  or  single  manager  would  be  applied  according  to  tlie  complexity  of 

I 

I the  interface  task  and  the  desired  intensity  of  management.  Both  would 

I have  the  advcintage  of  focusing  responsibility  for  interfaces  within  a 

single  element  while  requiring  only  small  commitments  of  human  resources. 
The  program  manager  who  chooses  to  leave  the  interface  job  to  his  func- 
tional specialists  without  creating  a responsible  focal  point  should  not 
be  anticipating  any  problems  or  uncertainties.  His  assessment  of  the  in- 
terface job  to  bc’  done  should  have  concluded  that  a single  fiuiction  such  as 
technical  integration  or  coipatibility  testing  is  all  that  is  rtxpiired. 
Usually,  this  approach  will  be  taken  when  the  item  to  bc'  integrated  is 
rf f-the-shelf  or  an  inventory  item. 

A progr£im  manager  should  avoid  over-sinplifying  interface  problcmis. 
One  of  the  most  fertile  areas  for  generating  unegx:!Cted  trouble  can  bt' 
the  interface  with  an  off-the-shelf  system.  For  exanplo,  fighter  air- 
»*  craft  being  built  today  are  having  to  carry  and  deploy  short  range  missili's 

’ such  as  earlier  Aim-9  series  that  date  back  to  the  1950's  and  19f)0's. 

Problems  are  continuously  japping  uf)  fecause  these  vintaeje  wi'atxms  w»'ri' 
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not  dcsicjncd  fcr  or  testcxi  to  the  severe  carriage  environment  which 
exists  on  the  latest  high  performance  aircraft. 

ii 

Joint  Servoce  Progr.mis 

Qiining  control  over  parts  of  another  manager's  procjram  becanL--s 
much  more  difficult  when  that  other  program  is  a joint  service  undertaking. 
The  reason  can  bc'  e.xplained  in  two  words,  "decreased  flexibility."  This 
is  especially  true  if  the  other  service  is  the  executor  of  the  prcxiram. 

IVliat  it  Lxiils  dcDwn  to,  is  that  your  own  service  counter[xirt  in  a joint 
protjram  office  can  only  be  responsive  to  your  needs  to  the'  degree  that 
tile  executive  service  concurs  or  is  not  affected. 

A procjram  nnnager  must  bc  aware  of  the  uphill  battle  his  own  ser- 
vice cxiunterjvirt  is  waginej.  The  executive  service  will  likely  have  dif- 
ferent recjuirojiK'nts.  If  the  particiixiting  service  has  peculiar  ncxxls  tliey 
will  have  to  push  loudly  for  consideration.  There  may  bc'  times  whc'n  a 
prcxjnim  manager  has  to  tlirow  tlie  weiciht  of  his  cxvn  procjram  bc'hind  a rc'- 
cjuiremi'nt  in  order  to  forex?  its  cons idc'rat ion.  All  tlu'se  activdtic'S  must 
take  plaa?  within  the  conte.xt  of  formal  intc'rsc'rvict'  agrex'ments  whicli  are 
(juile  neec'ssary  and  do  protect  individual  sc'rvicx'  nexxis  but  furthc>r  dc'- 
cre<ise  the'  flexibility  of  resjxansc'  acrex's  the'  intc'ifacx'. 

'['hc'  "Tiger  Tt'am"  Ajyroach 

At  sonic'  [xiint  in  a projiMm  the'  int c'r f.ux'  iivinacjc'r  luiy  Ix'  hit  with 
.in  unc'xjx'ctc'd  pmblt'm  of  st'rious  exinscxjuc'iicx'  whicdi  rtxx'ivc's  iniuxliatc'  and 
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hitjh  level  vis^iijility  .ind  rctjuires  (.piick  resolution.  The  problem  muy  ix’ 
one  of  those  "unknown-unknowns"  (3:15)  tJiat  carry  with  them  the  [xjtential 
for  desitpi  chanqes  and  eidverse  cost  and  schedule  imtjact.  This  t^qx'  of 
problem  can  occur  late  in  the  develotmxnt  and  test  phast  or  even  in  [jro- 
duction  or  operational  deployment  (iiase.  Thouqh  occurriinj  late,  its 
"unknown"  nature  may  rexjuire  cjoint7  back  to  fimdanvental  relationships 
addressed  much  earlier  in  the  prociram. 

An  example  of  this  ty^xi  of  interface  prc:>blem  tcx>k  place  in  197(> 
and  affected  both  the  F-15  mid  the  Aim- 71'  prex^rams.  liurint)  a joint  I'ol- 
low-on  Ojxprational  Test  and  IValuation  (FOTt,R)  proi^ram  in  the  sprinq  of 
that  year,  a setxiration  problem  was  discovered.  The  problem  cant-  aftin" 
years  of  develojmnt  and  tests  that  had  includi'd  tiundrcxls  of  hours  of 
wind  tunnel  work,  simulation  riuis  and  analytical  i''ffort,  alonq  with  ovm 
eicjhty  actual  firinqs  off  of  test  aircraft.  It  cxicurrcx’  in  a part  of  the 
envelofx?  that  had  not  Ixx'n  c'onsidc'rcxi  sr>verc'  for  sc''piration  purposes. 

Still,  it  hapfx''ncHj.  IVliat 's  iixire,  it  ha[itx''ncxi  at  a t iiio  whi'ii  Aim-7F  pro- 
duction fiuadinct  was  lx:'inij  e.xaminixl  Ix'forc'  Conqress.  It's  (x'currt'ncx'  niitxxi 
i|uestions  of  cximfxitibi  1 ity  and  ojx'rat  ional  sui t.ilii  I i ty  of  the  F-15/Aim-7F 
wt'apin  contiination  at  the'  warst  [xassibk^  tinx'  of  thi'  v'oar. 

Tnterfacx'  problems  in  the  c’onte.xt  just  descrilx'd  rtxjuire  an  I'xt  ra- 
ordinary  aptirotach.  The'  "Tie|er  Team"  is  suc-h  an  apnaxich.  It  cmu  U> 
extremely  effc'ctive,  thouqh  it  shouUl  not  lx"*  ovetaistxi  Ix'cmusc'  it  e\>nsvni»'s 
resources  at  a heavey  rate.  The'  tc'mn  is  nvick'  up  of  t'xp'ii  s t re«ii  ki'y 
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organizatons  involved  in  the  interface.  In  the  case  of  the  F-15  prc±)lem, 
the  team  was  ccmposed  of  representatives  of  both  contractors  (aircraft 
and  missile)  and  both  program  offices,  with  additional  participation  from 
the  test  center  and  the  using  comend.  In  scmvs  cases,  outside  help  such 
as  from  government  laboratories  may  be  required. 

To  bo  effective  a tiger  team  must  be  chartered  by  and  have  the 
absolute  support  of,  top  rrenagement.  Participants  should  be  given  auth- 
ority to  commit  resources  towaurd  a solution.  An  action  plan  is  formulated 
early  in  the  life  of  a tiger  team.  Because  of  the  uncertainties  usually 
present  the  plan  may  be  incremental  in  nature.  Activities  tend  to  be 
structured  in  short,  intensive  packages  with  milestones  spaced  only  two 
or  three  weeks  apart.  The  team  meets  at  least  that  often  to  evaluate  past 
results  and  refine  future  actions.  Utien  team  nranbcrs  are  not  meeting 
with  each  other,  daily  conrriunication  is  maintained  to  assure  that  all 
activities  are  on  course. 

This  intensive  activity  is  maintained  throughout  the  critical 
phases  required  to  solve  the  problem.  Some  problems  may  require  only  a 
few  weeks  of  tiger  tccui;  effort,  others  noy  take  si.x  months  to  a year  to 
resolve.  The  samt?  level  of  intensity  is  riviintained  during  the’  tint’  that 
the  team  is  engaged.  If  the  intensity  begins  to  drop  off,  it  should  be 
taken  as  a sitjn  that  the  tiger  team  approeich  may  no  longer  Ix'  rexjuirexi. 
Rccognizincj  that  ticie>'  teams  are  a costly  use  of  resources,  returning  the 
problem  to  a mt^re  nomval  course  of  doing  business  shcxild  Ix’  a fnxjiu'nt 
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consideration  as  events  unfold.  A tiger  team's  numlx^r  one  objcjctive 
should  be  to  work  itself  out  of  existence. 
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aiAPTI-;R  ITT 


PRX'.IWI  awreil.  OF  AN  PTn-:RFACF 
Multiple  Procjrani  Direction 

ProqrcJin  direction  as  containcxl  in  Decision  Coordinatinq  Papc'rs 
(DCP's)  , Prociram  Manaqemcait  Directives  (PMD's)  and  other  fomul  diroctinq 
docunt'nts,  is  the  startinq  (x>int  for  scopinq  out  iin  interface  manaqement 
task.  Individual  procjram  rcsfxinsibilities  as  well  as  resixjnsihilitics 
across  the  interface  should  be  conplctely,  unambitjuously  and  consistiintly 
defined  in  each  prcxirani's  directives.  Interface  niana()ors  must  pay  almost 
as  close  attention  to  the  direction  applied  to  the  prociriim  with  wtiich  they 
arc  interfacing  as  tliey  pay  to  ththr  own.  Inconsistencies  should  not  ix' 
tolerated.  Hiciher  headejuarters  must  lx-  nvidt'  aware  of  procjram  interrela- 
tionships so  th.at  they  oan  avoid  unilateral  chancres  in  direction  to  one 
program  if  the  other  is  afhxrtLxl.  Desircxl  c’h.anqes  in  procir^im  direction 
should  b('  coordinated  and  imfjlenxxitt'd  simultantxausly  down  throiKjh  Ixilh 
protjram  channels  in  c:>rder  to  presoin^e  responsiveness  across  tht'  prcxjriuii 
interfaces.  Prexjram  iranaqers  must  reco<inize  that  tliey  have  a resixinsibi  1 ity 
to  t'ducate  thc^  bureaucracy  on  certain  prexinun  int  errelat  ionships.  (kxxl 
prexiram  direction  is  a two-way  strext. 

Inter  fag."  Prcxjr.im  P 1 ans 

OncT'  a nvanatT^'r  luxk'rst.inds  his  interfag''  resfxxisibi  1 it  ic's  as 
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contained  in  his  program  direction,  he  is  ready  to  develop  an  interfaci' 
plan.  Good  planning  is  at  least  as  important  to  interface  nnna<jemcnt  as 
it  is  to  any  other  management  form.  An  interface  plan  is  a ccrminication 
vehicle.  It  communicates  responsibilities  for  actions.  It  describes  the 
actions  required  along  with  the  sequential  ^^nd  interdependent  relation- 
ships involved.  When  all  the  actions  in  an  interface  plan  are  ccxnpleted 
and  added  together  they  should  result  in  the  successful  integration  of 
two  or  more  interfacing  systems.  All  parties  who  have  a role  in  inter- 
face management  must  have  access  to  the  plan.  In  cases  vdiere  direct  in- 
volvement is  limited,  the  interface  program  plan  may  be  the  prinviry  memis 
of  communicating  actions  and  requirements  across  responsible  agencies. 

The  form  that  an  interface  plan  can  take  will  depend  on  the  inter- 
face approach  selected.  For  exanple,  vdiere  tlie  govemirent  has  opted  to 
the  integrator,  the  plan  may  be  an  adjunct  to  a nimiorandum  of  agreement 
between  the  program  offices  that  will  bo  sharing  the  responsibility.  Or 
a single  program  office  may  have  total  integration  resix>nsibility  wiiich 
it  may  retain  or  pass  on  to  a prime,  integrating  contractor.  In  the 
former  case  tlie  integration  plan  nught  be  a part  of  the  overall  prexjram 
nnnagement  phin,  vdiiie  in  the  latter,  it  may  take  the  form  of  a contractual 
document.  Certainly,  there  are  other  forms  and  ap[)roaches  or  tx>mbinat  ions 
that  can  be  used  under  varying  circumstances,  l^^hatover  form  the  plrni  takes 
hewever,  its  utility  will  bc^  determintxl  by  its  disstmiination  and  relevancy. 
An  interface  program  plan  nuist  be  made  available  to  everyone  involvtxl  and 
must  be  kept  up  to  date. 
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Joint  IJindinij 


IJuuiinq  arranqomt'nts  for  interface  nvinaqenvnt  should  Ix^  detemiined 
as  early  as  [X)ssible  in  a procjram.  Early  at^rcvnients  as  to  fundi nq  res- 
txmsibility  are  essential  to  developinq  a soiuid  fiuidimi  plan.  The  distri- 
bution of  fiuidinq  res[.xjnsibi  I ity  will  v'ai-y  qreatly  from  one  interface  pro- 
qram  to  another.  Clear  prociran  direction  as  ntentioned  t'arlier  will  qo  a 
lonq  way  tcTward  defininq  who  [.uys  for  wtiat  tiurinq  tJie  develotnK.'ut  and  test 
activities  involvdnq  two  c.ir  nore  systems. 

In  the  real  world  ot  pixxjram  uunaqeiiont  , direction  noy  not  always 
Ix'  clear  mill  concise.  A qocxl  workinq  ridat  ionship  Ix'twix'u  the'  prixiram 
nvinaqers  involved  Lx'conx's  espi'cially  crit  ical  when  prixp-am  direction  is 
vaiuK.'.  If  ariTunients  over  who  is  suppo.se  to  [viy  lor  v/hat  are  allowi'd  to 
exist,  usually  nothinq  qets  done  and  Ixith  sides  suffer.  M.iny  t iiix's  it 
is  wiser  to  (\ay,  if  you  have  thi'  fluids,  even  thouqh  a case  cixild  Ix'  made 
for  tlK’  other  firixjram's  havinq  the  res^xinsilii  1 ity.  The  other  prixiram  nun- 
aqer  nviy  not  havx'  the  nxiney,  so  hanqinq  tlie  re.sjxinsibi  1 ity  around  his  neck 
isn't  qoinq  to  accxinifil  ish  your  objectives.  On  the  otlier  hand,  with  a qixxi 
wi>rkinq  relat ion.ship,  in  an  atiiosphere  of  qive  and  take  accxirdinq  to  wiio 
has  till'  resources,  Ixith  prcxmim  nvinaqers  iMuld  reap  Lx'iiefits  in  tJx'  lonq 
run. 

tVlieji'  a sfx'cific  prexjram  is  in  its  life  cycdi'  can  Ix'  a di'tenninant 
of  fiuidinq  res[xinsibi  1 ity.  For  exanijilt',  e.irly  in  the  I’-l'i  prixirmii  a 
desiiin  chatuie  to  thi'  Aim-7F  missile  autofulot  was  nxiuinxi  in  ordi'r  to 
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provide  missile  stal^ility  durinq  seixiration  from  the  aircraft.  Witli  the 
F-15  in  the  early  staqes  of  developmt'nt , an  agrcxaicnt  with  the  Aim-7F 
joint  program  office  was  nude  whereby  F-15  funds  wc're  used  for  the  missile 
research  and  tleveloim^nt  effort  and  Aim-7F  funds  were  used  to  implemtait 
the  change  in  prociuction.  FSeveral  years  later  an  analocpus  situation 
cxx'urrcxl  wliich  rotiuirixl  an  additional  missile  autopilot  ntxlification. 

The  st'cxtnd  tira'  aroiuid  the  Aim-7F  joint  prcxiram  office  picked  up  most  of 
the  costs,  with  the  F-15  prcxiram  fimding  only  tlio  flight  test  portion  of 
the  effort.  In  the  first  instance  the  F-15  had  been  trailing  the  Ain>-7F 
in  develo{xixxit , in  the  second  case,  the  F-15  v;as  leading  tine  Aini-7F  into 
the  operational  inventory'.  The  shift  in  relative  positions  between  the 
two  protirams  precipitattxl  a different  sharing  arrangement  on  funding  res- 
ixnnsibi  1 ity . 

Another  factor  influencing  joint  funding  arrangenunts  is  precedent. 
A prcK7ram  manager  wtio  identifies  his  test  and  develofirent  hardware  needs 
early  can  tirke  advantage  of  sone  fiuading  precedents  in  order  to  ease'  his 
dollar  burden.  Identifying  specific  t|uaiatities  of  air-to-air  missiles 
for  testing  as  an  examj^le,  allows  the  retjui remen ts  to  be  includexl  in  the.' 
missile  procurement  and  allocation  planning,  tlnce?  an  allocation  has  bee'ii 
made  to  a specific  aircraft  test  program  the  dollars  conx'  out  of  missile 
prcxnjrement  funds  and  tiie  aircraft  proegnam  manager  netxi  only  fauxl  for 
test-pt'cul  iar  harrtware  (i.e.  tcleiTX’try  packs,  etc  .). 


Program  Reporting 

When  reporting  the  status  of  his  program  to  his  superiors  and  to 
the  Congress,  today's  program  manager  must  "demonstrate  a knc^\'ledge  of  the 
program  in  the  widest  context."  (3:6)  If  his  program  includes  one  or  more 
interfaces  with  other  major  weapons  acquisition  programs,  that  context 
will  necessarily  include  a good  deal  of  the  other  program's  status.  An 
aircraft  program  manager,  for  example,  is  expected  to  know  the  status  of 
his  primary  air-to-air  missile  even  when  another  service  is  developing  it . 
Often  times.  Service,  OSD  and  Congressional  leaders  will  receive  separate 
briefings  on  interfacing  programs  at  close  intervals.  They  will  likely  be 
COTparing  notes.  Especially  if  joint  testing  is  in  progress  and  both 
program  managers  are  reporting  results.  Under  these  conditions  it  is  im- 
portant for  interface  management  relationships  to  include  a means  of  ex- 
changing program  status  information,  and  for  coordinating  what  is  to  bo 
reported  on  up  the  chain  of  command.  In  short,  a program  manager's 
ability  to  instill  confidence  in  his  superiors  concerning  his  own  procjram 
may  be  extended  into  program  areas  concerning  an  interfacing  program  if 
he  has  intimate  knowledge  of  the  latter  at  his  command.  There  are  times 
when  program  managers  must  help  each  other  in  this  way,  especially  if  one 
has  more  clout  or  is  blessed  with  more  streamlined  reporting  channels. 
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aiAITER  IV 


THE  GOVEH-JMENT  - CONTRACrOR  TEAM 
The  Role  of  the  Contractor 

Given  several  alternative  approaches,  what  role  in  interface  nvan- 
agement  should  a program  manager  allocate  to  his  contractor (s) ? In  chajj- 
ter  II  wo  saw  how  factors  such  as  the  acquisition  environment  and  inter- 
organizational  relationships  influence  how  a program  manager  might  struc- 
ture his  cwn  organization  to  do  the  job.  Many  of  the  same  factors  will 
influence  the  role  that  contractors  should  play  on  the  interface  rranago- 
ment  team.  The  prudent  interface  manager  will  tailor  his  approach  to  his 
particular  situation.  If  he  knows  V\Aiere  the  strengths  and  weaknesses 
lie,  he  can  build  on  tiie  former  and  work  around  the  latter.  If  the  bulk 
of  the  system  expertise  has  been  retained  by  the  contractor,  as  iin  ex- 
ample, and  the  government  has  acted  primarily  as  a manitor,  then  strong 
consideration  should  be  given  to  naking  the  contractor  the  integrating 
agent.  the  other  hand,  vdiere  the  government  may  have  been  the  de- 
siejner  and  the  contractor  primarily  the  producer,  a government  integrator/ 
contractor  supporter  type  role  might  be  callcDd  for. 

The  elements  of  risk  and  uncertainty  can  play  a large  jart  in 
determining  roles  on  the  interface  team.  When  one  side  of  the  interface 


is  a stable,  mature  and  a baselined  system,  the  government  may  accept 
the  low  risk  of  providing  only  interface  data  to  the  contractor  develop- 
ing the  other  side  vvhile  requiring  that  he  be  conpatible  with  the  mature 
system  as  specified  by  the  data.  On  the  other  hand,  if  both  sides  of 

the  interface  are  under  development  and  subject  to  high  risk  conditions,  i 

the  government  my  elect  to  pay  one  or  more  contractors  to  assune  the 
responsibility  (and  the  risk)  of  making  the  systems  ccxipatible.  The  con- 
tractor who  is  thus  given  total  system  responsibility  for  interfacing  with 
the  other  system  will  naturally  price  out  his  effort  to  manage  the  inter- 
face and  will  include  contingencies  for  the  risks  involved. 

The  Associate  Contract  Approach 

In  Chapter  II,  under  organizational  relationships,  we  discussed 
how  a program  manager  could  maximize  his  control  over  a critical  interface 
by  organizing  as  though  the  other  program  were  a subsystem  of  his  own. 

We  also  discussed  how,  in  today's  scare  resource  environment,  most  pro- 
gram nenagers  will  not  enjoy  such  an  opportunity.  There  exists  however, 
an  alternative  that  provides  sorre  of  the  controls  inherent  to  the  subsys- 
tem approach.  The  program  manager,  by  passing  Total  System  Performance 
Responsibility  (TSPR)  to  his  prime  contractor  c£in  precipitate  an  associate 
contractual  relationship  between  the  contractors  themselves.  If  the  con- 
tractor having  TSPR  enters  into  a direct  contract  with  the  contractor (s) 
responsible  for  the  system  to  be  inter faceci,  a great  deal  of  the  control 
that  characterizes  the  sul^system  a[)proach  con  be  rcalizal.  T)iis  is  es- 
pecially troK'  when  both  sides  of  th«'  interface  are  under  dcvelofnent . 
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A very  importijnt  aspect  of  an  associate  contractor  relationship 
is  the  resultant  ability  to  go  beyond  the  specifications.  With  expertise 
from  both  sides  of  the  interface  interacting,  sensitivity  analyses  and  trade- 
offs can  be  imde  with  much  more  freedom  and  at  lower  levels  of  specificity 
where  that  flexibility  exists.  This  can  lead  to  a sounder  integration 
effort  that  not  only  ireets  performance  and  form,  fit  and  function  re- 
requirments,  but  leaves  behind  a level  of  intersystem  understanding  that 
would  not  be  achieved  otherwise  (in  this  regard,  it  takes  on  the  appear- 
ance of  a prime  - subcontractor  relationship) . This  understanding  can 
become  invaluable  later  if  unforseen  compatibility  problems  arise  or  vhen 
one  or  both  sides  of  the  interface  are  subjected  to  engineering  changes. 

In  the  case  of  integrating  a missile  with  an  aircraft,  the  asso- 
ciate contract  approach  provides  a unique  opportunity  for  the  missile 
contractor  to  influence  the  aircraft  design.  It  also  provides  for  system 
compatibility  problems  to  be  solved  in  the  most  cost  effective  manner  by 
considering  solutions  on  either  or  both  sides  of  the  interface.  As  an 
example,  difficult  aircraft  - missile  separation  problems  were  solved  on 
the  F-15  aircraft  by  a combination  of  aircraft  flow  field  and  launcher 
modifications  along  with  an  Aim-7F  missile  autopilot  change. 

The  Role  of  the  Government 

The  contractor  team  created  through  associate  contracts  is  most 
effective  v\hen  the  government  rranagers  support  their  efforts  in  a fac- 
ilitative  role.  Through  such  means  as  authorizing  direct  exchange  of 
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program  information  and  data  among  contractors  and  by  providing  govern- 
ment furnished  ec]uipment  channels  for  the  exchange  of  hardware,  the  mil- 
itary program  managers  enhance  the  flexibility  and  res[Jonsiveness  of  the 
contractor  tean). 

The  facilitative  role  of  govemirent  managers  should  not  be  mis- 
taken for  non-participation.  In  fact,  the  role  requires  a high  degree  of 
participation.  The  objective  is  to  provide  for  smooth  and  easy  flow  of 
information,  data  and  hardware  between  interfacing  contractors.  This 
requires  that  the  government  managers  establish  purchasing  arrangements 
in  several  directions.  To  illustrate  this  point.  Figure  2 shews  the 
arrangements  utilized  in  the  F-15/Aim-7F  integration  program. 

In  addition  to  the  facilitative  role,  each  individual  program 
nnnager  will  participate  in  the  interface  program  through  his  prime  con- 
tract at  least  to  the  sane  degree  that  he  participates  in  the  management 
of  his  basic  program.  Also,  the  most  important  role  of  the  governnx^nt 
manager  includes  those  activities  described  earlier.  That  is,  ho  provides 
the  environment  for  interface  managenent.  By  comnunicat ing,  educating  ami 
interacting  with  the'  bureaucracy,  he  ensures  that  the  cjoals  of  the'  inte'r- 
face  team  are  consistent  with  overall  prexjram  and  highem  oreier  ejexils,  anei 
that  resexircx's  are  available  and  ccxiinittable  to  the'  task. 
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SOME  FACILITATING  ARRANGEMENTS 


CHAPTER  V 
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I THE  INTERFAQ^  MANAGEMENT  PROGRAM 

F 

! Sunroary 

j Most  program  managers  continue  to  be  faced  with  ccmplex  interface 

problems.  Today's  environnent  oL  scarce  resources  and  multi-national  under- 

i 

j takings  rarely  affords  the  modem  manager  control  over  all  of  the  elements 

of  his  system.  Emphasis  on  joint-service  developnents  has  increased  the 
interorganizational  carplexity  of  integration  programs.  Sentiment  a- 
gainst  the  proliferation  of  system  peculiar  equipment  has  served  to  nvike 
comronality  an  important  program  consideration. 

Forced  to  consider  more  interfaces,  the  procjram  iranager  is  dis- 
covering a need  to  go  beyond  the  proven  methods  of  integrating  the  phy- 
sical and  functional  aspects  of  hardware.  Joint  or  conplimenting  pro- 
gram direction,  mutual  funding  agreements,  multi-program  rejx^rting,  and 
joint  testing  have  beconG  necessary  considerations  in  many  of  texlay's 
major  weapon  system  programs.  In  effect,  the  interface  ntuiagement  iob 
has  taken  on  most  of  the  characteristics  of  basic  prexp-am  nnna(ienx''nl  . 

/ Conclusion 

y. 

It  beconx'S  U5«?ful  to  apjiroach  nvijor  interface  nvinacjeiix'nt  tasks  as 
interface  manac|em'nt  prot^rams.  Recalling  the  cxincept  of  thi'  [Hysicnl/ 
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functional  interface  as  presented  in  Chapter  I,  we  can  now  inodify  that 
cx>ncept  as  depicted  in  Figure  3.  Frcm  this  viewpoint,  the  interface  nian- 
<iger  is  seen  to  have  a program  within  two  interfacing  programs.  Position- 
ing the  manager  in  system  program  office  "A"  as  an  exanple,  ho  has  a com- 
plete interface  program  to  mcinage.  In  the  fundamental  sense,  he  is  res- 

' ponsible  for  maintaining  an  optimum  balanc:e  of  cost,  schedule  ccnd  per- 

^ formance  for  his  interface  program  (the  inner  circle) . This  report  has 

} 

j attenpted  to  shew  that  many  of  the  conmon  conc:ems  and  problesms  of  pro- 

gram rranagement  will  bo  present  within  that  smaller  circle. 

l^at  is  also  apparent  from  Figure  3 is  that  the  interface  program 
has  three  distincitve  parts.  Part  1 will  inclucie  areas  peculiar  to  system 
A,  and  will  be  subject  to  maximum  control  by  the  intorfac:e  manager  \4io 
resides  in  that  system  program  office.  The  middle  part  (cross-hatched) 
will  be  conmon  to  both  systemis  A cmd  B and  subject  to  less  cxDntrol  Ix'- 
cause  of  the  neexsssity  to  satisfy  niutual  program  rcxguiromcmits.  Part  3 
being  peculiar  to  system B,  represents  the  minimum  control  portion  to  the 
system  A manager.  But  all  sections  arc  part  of  the  interface  program, 
Problems  in  any  one  will  affect  the  entire  prociram.  No  part  can  be 
neglected  because  of  lack  of  control.  In  fact,  the  least  controllable 
portion  will  at  tinos,  demand  the  most  management  attention  and  innova- 

r 

^ tion.  'fkf'  final  conclusion  then,  is  that  Fugirt'  3 can  tx'  a mtxiel  tor 

interfacx'  nvinacfenent . First,  it  revc'.ils  th.it  an  int('rfa<x>  r<  i jui  r<’m 'itl 
is  really  a mini-i-)rcx(ram  within  two  or  mon'  ititeract  ing  pnxn.un.s, 
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requiring  the  application  of  most  of  the  fundairentals  of  good  program 
mnagencnt.  Lastly,  it  presents  the  concept  of  three  distincitive  levels 


! 

1 

I 

'!■ 

i 

of  control.  And  control  is  the  essense  of  any  interface  management 
j approach. 
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FIGURE  - 3 


TOTAL  INTERFACE  MANAGEMENT 
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